Add SyncStatus field to RelatedResourceSpec#175
Conversation
cfd1dd0 to
64562ba
Compare
|
/test pull-api-syncagent-verify |
64562ba to
31a3e65
Compare
31a3e65 to
2d838c5
Compare
Signed-off-by: Iskren <iskren@kubermatic.com> some codeverify fixes sdk changes Signed-off-by: Iskren <iskren@kubermatic.com>
…atusForward Signed-off-by: Iskren <iskren@kubermatic.com>
2d838c5 to
0c638ce
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@embik Thanks for the review. Can you take a look when the e2e tests are finished? |
Sure thing! The PR looked ready for review, apologies. |
SimonTheLeg
left a comment
There was a problem hiding this comment.
Overall this looks fine to me. I have one small nit, but that is about it. It took me a while to wrap my head around why we need to jump through all these different cases between spec and status, but yes given that we work with unstructured data mostly and our current architecture, this looks correct to me.
I'll leave the final verdict to @xrstf
| name: subnets.aws.example.com | ||
| spec: | ||
| group: aws.example.com | ||
| scope: Namespaced | ||
| names: |
There was a problem hiding this comment.
let's please not use any vendor specific language, like "aws" here.
And if it needs to be changed, I would strongly be in favor to renaming this to something like crontabswithstatus. That also clearly indicates to others why we need another CRD for this use case
There was a problem hiding this comment.
The short version is - spec and status are separate API endpoints even if they look like one object, so they need separate write calls. And that's why status sync always runs even when spec just changed - otherwise you would miss the status update on that cycle and need to wait for next reconciliation.
…tStatusForward Signed-off-by: Iskren <iskren@kubermatic.com> resolved nitpick
0c638ce to
4a45463
Compare
|
/test pull-api-syncagent-test-e2e-kcp-0.30 |
Summary
Adds a
syncStatusfield toRelatedResourceSpec. When set totrue, the status subresource of a related object is synced in the same direction as its spec:origin: kcp-> status flows kcp -> service clusterorigin: service-> status flows service cluster -> kcpThis is independent of the existing
syncStatusBackbehavior on primary resources (which always syncs status in the reverse direction).Example
Changes
sdk/apis/syncagent/v1alpha1/published_resource.go- newSyncStatus boolonRelatedResourceSpec; adds a CEL validation rule that rejectsorigin: service + syncStatus: truewithout awatchconfiguredinternal/sync/object_syncer.go- newsyncStatusForwardfield andsyncObjectStatusForward()method (returnserroronly); called unconditionally fromsyncObjectContents()so a simultaneous spec+status change doesn't defer the status sync by one reconciliation cycle; includes a 404 guard that emits aWarningevent instead of error-looping when the destination CRD has no status subresourceinternal/sync/object_syncer_test.go- unit tests forsyncObjectStatusForward()(5 sub-tests covering no-op conditions, happy path, and 404 guard) andsyncObjectContents()status-runs-even-on-spec-requeue invarianttest/e2e/sdk/cel_validations_test.go- three new cases inTestValidateRelatedResourceSpeccovering rejection oforigin: service + syncStatus: truewithout watch, and the two valid combinationsinternal/sync/syncer_related.go- wiresSyncStatusintoobjectSyncer: setssyncStatusForwardand adds"status"tosubresourcesdeploy/crd/kcp.io/syncagent.kcp.io_publishedresources.yaml- regenerated CRDtest/crds/subnet.yaml- new test CRD with status subresourcetest/e2e/sync/related_status_test.go- three e2e testsTesting
Unit tests (
make test) — all pass, including 6 new sub-tests inTestSyncObjectStatusForwardandTestSyncObjectContentsForwardStatusRunsEvenOnSpecRequeueFocused e2e — three new tests covering the happy paths and the default-off behavior:
Full e2e (
make test-e2e) — 38/39 pass; the one failure (TestAPIExportEndpointSliceDifferentCluster) is pre-existing and unrelated to this change.What Type of PR Is This?
/kind feature
Related Issue(s)
Fixes #173
Release Notes